fix: reject unadvertised capability methods by default - #1446

Verified at a4b6647 (base f852ec0) by running a probe pair, not by reading the diff. Three asks, all small; none is about correctness of the two hunks you wrote.

Verification

Probe: serve_directly on a tokio::io::duplex(4096) pair at ProtocolVersion::V_2026_07_28, server = ServerCapabilities::builder().enable_tools().build() and no method overrides; same probe binary run on upstream/main and on your head.

With enable_prompts().enable_completions() declared, both calls still return Ok (completion values=[]), so the "keep the empty success when advertised" half works too. CI at a4b6647 is 24/24 green.

Your regression test is real: crates/rmcp/tests/test_with_js.rs is executed by the Run Tests (no local feature) job (cargo test -p rmcp --features <all except local>), not by Run Tests. Locally, cargo test -p rmcp --all-features --test test_with_js compiles the file to 0 tests because of #![cfg(not(feature = "local"))] — worth knowing before anyone concludes the JS check passed from a --all-features run.

No macro regression: #[prompt_handler] injects its own list_prompts and a get_info with prompts enabled (crates/rmcp-macros/src/prompt_handler.rs:57, :110), so the new trait default only affects handlers that rely on it.

Asks

1. resources/list and resources/templates/list keep the same hole. Rows 3-4 above: a server that declares no resources capability still answers both with an empty success, while read_resource, get_prompt, set_level and subscribe already return -32601 from their defaults. Issue #1445 calls this out explicitly ("list_resources, list_resource_templates and list_tools have the same Ok(default) defaults"). Gating the two resource defaults is two lines and the same shape as what you wrote; if you would rather keep this PR narrow, please open the follow-up and say so in the body so it does not get lost.

2. Pin the behaviour with a Rust test. Right now the only regression coverage is the npm-backed JS file — it is a genuine check (it does run in CI), but it costs a node install and disappears entirely under --all-features. A duplex test like crates/rmcp/tests/test_handler_cache_hints.rs:99-130 can assert both directions cheaply: tools-only server → -32601 for both methods, declared server → Ok.

3. Say the behaviour change out loud. Servers that never declared prompts/completions but relied on the default empty success will start receiving errors from the next release. A line in the PR body and in the release notes (see VERSIONING.md) is enough; it is a fix, not an API break, but clients of such servers should not be surprised.

I am not approving until these are answered — ask 1 is the one I would like to see resolved in this PR.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 292142dccb

I read the changes in crates/rmcp/src/handler/server.rs and the new test_default_list_capabilities.rs, plus the fixture updates. Two checks and one question:

1. This completes an existing pattern rather than inventing one: get_prompt, call_tool, read_resource, subscribe and set_level already returned method_not_found from their defaults, so gating the five list/complete defaults on the advertised capability is consistent with the rest of server.rs.

2. The gate lives only in the default implementations, so a server that overrides list_tools (or the other methods) is unaffected even if it does not advertise the capability. The CHANGELOG entry says "default ... handlers", which matches, but it is worth confirming that is the intended scope, since the behavior-change note could be read as broader.

3. get_info() is now consulted on every default list call. If a handler builds its ServerConfig dynamically from runtime state, the capability seen here could disagree with what was advertised during initialize. Is get_info() expected to be cheap and stable per handler? If so, a line in the trait docs saying so would pin the assumption down.

The test matrix (no capabilities, tools only, all enabled) covers the combinations well, and the fixture updates in the other test files show the blast radius was walked through.